Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
Mac and OpenDoc are trademarks of Apple Computer, Inc.
Introduction
After the OpenDoc Name Binding process has determined what part editor or part viewer is to be used in order to edit or view a given part or document, an editor must be loaded and a part instantiated. Please see the Binding and ‘nmap’ Recipe for information on how to set up an editor to be recognized by the OpenDoc Name Binding system. This recipe describes what code is required in order for an editor to be loaded under System Object Model™ for Mac™ OS (SOM for Mac).
Part Editor Loading
OpenDoc part editors are built as System Object Model (SOM) class libraries. SOM for Mac is written on top of the Code Fragment Manager (CFM). Therefore, there are a couple of things that are required in order for an OpenDoc editor shared library to be loaded and instantiated.
The CFM Connection Initialization Routine
Implementing a CFM Connection Initialization Routine (documented in Inside Macintosh: PowerPC System Software) is technically optional for OpenDoc, however there are certain situations where an editor will require it.
The most likely need for the CFM intialization function will be when an editor makes use of some of the OpenDoc utilty calls. For example, if an editor is using Macintosh resources, and is using the recommended OpenDoc resource utility calls, InitLibraryResources must be called from the CFM initialization function. (Note: using the OpenDoc resource utilties is not a requirement for using Macintosh resources in OpenDoc. Please see Inside Macintosh: PowerPC System Software for more information on using resources from a shared library if these utilites are not going to be used.) Likewise, if an editor is going to use any the optional ODMemory utility calls, the CFM initialization function is a goodplace for calling InitODMemory. See the OpenDoc utilities documentation for more information on these and other OpenDoc utilities.
It is also possible (but less likely) that an editor will want to make direct SOM calls in the CFM intialization function. See the SOMobjects™ for Mac™ OS documentation for more information on calling SOM utilties.
The following is a sample CFM intialization function:
// We are using ODMemory utility calls, so we will
// initialize the interface to the memory manager.
OSErr err1 = InitODMemory();
// We must also capture the relevant information about
// our library file so that we may access our resources.
OSErr err2 = InitLibraryResources(initBlkPtr);
return (OSErr) (err1 != noErr) ? err1 : err2;
}
The 'cfrg' Resource
A requirement for getting SOM to instantiate a part by name is a 'cfrg' resource that contains a fragment description corresponding the SOM Class ID (or the OpenDoc Editor ID) for an editor in a shared library. Some development systems will create a default 'cfrg' using the shared library's file name as the name of the fragment. SOM, however, needs the Class ID in the fragment, so another name needs to be added to any existing 'cfrg'. Note, also, that 'cfrg's differ on 68k and on PowerPC. The following is the PowerPC 'cfrg' resource from the editor for the OpenDoc EditorSetup Control panel:
